Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-isis-atipx-00.txt < prev next >

Wrap

Text File | 1993-07-08 | 59.8 KB | 1,416 lines

ISIS Working Group Radia Perlman Internet-draft Chris Gunner Digital Equipment Corp. June 1993 Further Integration of IS-IS; Appletalk, IPX, and Other Protocols Table of Contents 1. Status of this Memo 2 2. Abstract 2 3. Introduction 2 4. Issues To Consider 3 4.1. Disambiguating Native Mode Packets 3 4.2. Disambiguating Encapsulated Packets 3 4.3. When Is Encapsulation Desirable? 4 4.4. Metrics 5 4.4.1. IPX Ticks Metric 6 4.5. Propagation Of Protocol Y Routing Information 7 4.6. Limited Interconnectivity Over The Backbone 9 4.7. Making Configuration Easier 10 4.8. Accomodating Overlapping Addresses 11 4.9. When To Encapsulate 12 4.10. Tunnel Protocol 13 4.11. Routing Algorithm 14 5. Specific Proposal 15 5.1. Data Packet Encapsulation 15 5.2. "Protocols Supported" Field 16 5.3. Network Management Information 16 5.3.1. Parameters Node-wide (not Per Circuit Or Tunnel) 16 5.3.2. Parameters Per Circuit 17 5.3.3. Parameters Per Tunnel 17 6. Appletalk Specific Proposal 18 6.1. Appletalk Only Environments 18 6.2. Zone Information 18 6.3. LSPs 19 7. Specific Proposal for IPX 20 7.1. Ticks Metric 20 7.2. LSPs 21 7.3. IPX-specific Network Management Information 22 8. Security Considerations 22 9. References 22 10. Working Group information 23 11. Author's Address 24 Perlman (Internet-Draft expires end December 1993) [Page 1] Internet-Draft Further Integration of ISIS June 1993 1. Status of this Memo This document is an Internet Draft describing a method of extending the Integrated ISIS protocol (defined in RFC 1195) with routing information from additional protocols -- specifically NetWare IPX and Appletalk. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. This Internet draft expires at the end of December 1993. Internet drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. This is a draft document of the ISIS working group. Distribution of this memo is unlimited. Please send comments to the ISIS working group: isis@merit.edu 2. Abstract This document defines a method of extending the Integrated ISIS protocol (defined in RFC 1195) with routing information from additional protocols -- specifically NetWare IPX and Appletalk. 3. Introduction This document describes how to add support for new protocols into IS-IS. Once routes are calculated, a packet can either be carried in "native mode" or "encapsulated" in a Network Layer header supported by all the backbone IS-IS routers. This design allows network managers to configure which types of packets are encapsulated and which are carried in native mode. The document describes generic support for protocols other than IP and CLNP, and then describes specific packet formats for support of Appletalk and IPX. Perlman (Internet-Draft expires end December 1993) [Page 2] Internet-Draft Further Integration of ISIS June 1993 4. Issues To Consider 4.1. Disambiguating Native Mode Packets If multiple Network Layer protocols are being carried over a link, there must be a way to distinguish them. There is no way in general, by looking at the packet itself, that a protocol X packet can be distinguished from a protocol Y packet, unless we are extraordinarily lucky that either the independently designed protocols happen to be defined so that no packet from one could possibly be interpreted as a legal packet in the other, or that the people designing protocol Y took great care to design their packets to distinguish them from protocol X packets. Given that we can't count on being extraordinarily lucky, we must ensure that each data link provides a method of specifying the protocol type of the packet. Where protocols do (Ethernet, PPP), all that is needed is to get a value assigned for each protocol we wish to support. Where protocols don't (HDLC), we must provide some mechanism, for instance by adding a protocol type field in the beginning of what HDLC considers the initial portion of the data packet. Where a protocol defines multiple ways of doing it (802 LANs, which provide for SAPs for a few protocols, and SNAP SAP encoding for the others, where either 5 byte protocol types are used, or 2 byte Ethernet protocol types are used with a prespecified OUI), we need to specify which method should be used for each protocol supported, and define the values. 4.2. Disambiguating Encapsulated Packets The same problem occurs if we encapsulate various Network Layer protocols in a Network Layer header. Some Network Layer protocols (IP) have a "protocol type" field. Others (CLNP) do not. Probably the simplest method of providing protocol demultiplexing in CLNP is by adding a protocol type field to what would be considered the beginning of the data packet, in an encapsulated packet. In order to avoid having to administer yet another protocol type field, we should standardize on Ethernet protocol types (in which case the field would be 2 bytes), PPP protocol types (in which case the field would be 2 bytes), IP protocol types (in which case the field would be 1 byte), or 802 protocol types (in which case the field would be 5 bytes). The other possibility is to use the bottom byte of the destination address in CLNP (the "SEL" byte) as a protocol type field, and define the values to be the same as IP protocol types. In either case (if we use the SEL byte or we use the first part Perlman (Internet-Draft expires end December 1993) [Page 3] Internet-Draft Further Integration of ISIS June 1993 of the data as a protocol type), either we give a pointer to some other standards body that defines protocol types, or we have to give them out ourselves. 4.3. When Is Encapsulation Desirable? Let's assume that all the backbone routers support at least one common Network Layer protocol, probably IP or CLNP. Let's call the common Network Layer protocol "protocol X". A new protocol, say protocol Y, can be supported either in native mode or encapsulated with a protocol X header. Encapsulation of protocol Y packets is desirable if: 1. Not all backbone routers support protocol Y 2. There are multiple independent protocol Y networks with overlapping addresses, and the encapsulation allows extension of the addressing (see section on "domains"). 3. Protocol Y data packet format has limited capabilities, for instance a small maximum hop count as in the case of Appletalk. Encapsulating Appletalk allows the entire IS-IS backbone to be treated as a single Appletalk hop. 4. It might be easier to build high performance routers if they only have to forward a small number of network layer headers. So performance might actually be enhanced if there were only one packet format in the backbone. The disadvantages of encapsulation are: 1. It may be a performance problem for the encapsulating and decapsulating routers. Theoretically, encapsulating in a Protocol X header should be no different from encapsulating in any data link header, which any router must do when it is forwarding a packet. However, there are some router implementations that will forward much more slowly if they have to encapsulate or decapsulate. 2. It makes the data packets bigger. 3. If protocol Y packets can be large, it leads to the possibility of the decapsulating router having to do reassembly. Luckily with IPX and Appletalk, packets larger than 576 bytes are not allowed, so we can avoid fragmentation. Perlman (Internet-Draft expires end December 1993) [Page 4] Internet-Draft Further Integration of ISIS June 1993 4.4. Metrics Network Layer protocols evolve with their own routing protocols and metrics. If we were to support only protocol Y end systems, things would be much simpler, but we have to assume there are islands of protocol Y routers, and we have to interact with them without expecting anyone to modify the code in the protocol Y routers. Appletalk and IPX both compute a metric of hops (though IPX additionally computes a metric known as "ticks"). Both Appletalk and IPX use a protocol similar to IP RIP, and the maximum hops that can be reported is 15. The ticks metric for IPX is rather critical, since it is intended to give the Transport Layer a good estimate of the round trip delay. The IPX Transport layer does not measure round trip delay and adapt to it -- it takes the ticks value and sticks with it for the duration of a conversation (based on my knowledge of IPX). In this part of the paper, when we are discussing protocols generically, we will refer to "the RIP-like routing protocol that routes Protocol Y" as "GRP", for "Generic Routing Protocol". IS-IS has a link cost of between 1 and 64 (at least for CLNP and IP -it can be larger when reporting other protocols since the option for reporting a protocol Y destination in an LSP is not yet defined). If there is an IS-IS router R2 with a GRP neighbor R1, and R2 has computed a path cost to protocol Y destination D as 227, what is R2 supposed to report in its GRP message to R1? It is dangerous to ever decrease a metric, since the reachability of D can leak out some other part of the GRP island, and routing loops can be created, since D can look closer from the other end of the GRP island, even though D is not reachable within the GRP island. Various possibilities are: 1. Scale GRP metrics to IS-IS metrics. For instance, if the maximum path cost in IS-IS is 1023, then each GRP hop might be declared to equal a cost of 64. This requires the ability of reporting a link cost equal to 1023 (more than a byte). 2. Use hops (or whatever the protocol Y metric is) whenever reporting cost to a protocol Y destination. The way this would work is, suppose level 1 IS-IS router R2 is attached to GRP router R1. R2 hears, through GRP, that R1 can reach D at a cost of 5. R2 reports "6" in its LSP as the cost to D. Level 2 router R3, in the same area as R2, needs to Perlman (Internet-Draft expires end December 1993) [Page 5] Internet-Draft Further Integration of ISIS June 1993 report D in its level 2 LSP. It can figure out the number of hops on its IS-IS path to R1, add that to 6, to get the number of hops R3 should report as its distance to D. This has problems in that unless all level 2 routers in the area report D, and unless all level 2 routers in a foreign area leak information about D into their LSP, the apparent cost to D can rise quickly, and become greater than 15 ----------+ +---------+===========+----------+ D GRP | | | level | | cloud R1--+-R2 area R3 2 net R4 area R5--R6 ----------+ | | | | +---------+===========+-----------+ 3. A variant on the previous strategy is to only increment hops by 1, each time the cost to D is leaked from level to level. So in the previous case, R2 would report 6 in its LSP, as the cost to D. R3 would report 7. Level 2 router R4 in a foreign area would report 8. Level 1 router R5 in R4's area would report 9, to a GRP neighbor R6. I'll call this method "pseudo-hops". Pseudo-hops has two slight disadvantages. First of all, it does not allow computation of optimal interarea paths, since there's no way to really compare the cost of the path to D through two different level 2 routers. (But there is no real reason to optimize Protocol Y routes when we feel it is OK to send interarea CLNP traffic to the nearest level 2 router). Second of all, it means (as in the case of Appletalk), that a destination might appear reachable to routing, but actually be unreachable because the path is more than 15 hops, and therefore the data packet will not survive the journey. Again, this is not too serious. If this is a problem then the network can be configured to use encapsulation when actual paths exceed 16 hops, if there is a protocol with that limitation. I advocate advertising reachability of protocol Y destination D with either a real IS-IS cost or with pseudo-hops. A real IS-IS cost is preferable and is used when D is directly reachable from the IS-IS router reporting D in its level 1 LSP. Pseudohops is used when the reachability of D is discovered through GRP, when summarizing information into or out of an area. 4.4.1. IPX Ticks Metric With IPX, we need to be able to give a reasonable approximation to what IPX RIP would calculate as ticks. I suggest we report Perlman (Internet-Draft expires end December 1993) [Page 6] Internet-Draft Further Integration of ISIS June 1993 two metrics when reporting IPX destinations. The first metric will either be an IS-IS cost or pseudohops. It is used for actually calculating the path to the IPX destination. The second metric is ticks. We could require every link in the network to be configured with a ticks cost in addition to other metrics. Instead, I'd recommend that we configure a "ticks scaling" parameter. IS-IS metrics ought to be roughly proportional to delay, just like ticks are. However, they might be scaled differently than IPX nodes are expecting. If IPX is integrated into an already operating network, it is not reasonable to reconfigure all the link costs so that the ticks metric will be right. Instead, giving a scaling factor, like saying that the IS-IS configured default metric is 5 times the IPX ticks, (and you'd round up after division) will probably suffice. 4.5. Propagation Of Protocol Y Routing Information With CLNP and IP, level 1 routers only need to know which destinations are reachable in the area. If a destination is not reachable within the area the packet is sent to the nearest level 2 router. With CLNP the area is explicitly in the address. With IP, any address not reachable in the area can be concluded to reside outside the area. CLNP was designed for hierarchical routing. The reason IP routing can work this way is because of the ability to summarize a lot of destinations by advertising a short mask. In the case of IP, it is possible to advertise "default route", which is a mask of all 0's. Unfortunately, IPX and Appletalk have no means of summarizing routing information. Even if IS-IS routers were capable of coping with the concept that anything not reachable in the area is reachable outside the area, they would not be able to give routing information to a neighboring GRP router. In the case of IPX, every network number must be explicitly stated to the RIP neighbor, or it will assume that network is not reachable. Likewise with Appletalk, though Appletalk does have the concept of network number ranges. Theoretically, one could use a huge range as sort of a "default route", but Appletalk routers cannot cope with overlapping address ranges, and there are higher layer protocols that need to translate from "zone names" to specific network number ranges for the LANs on which those zones reside. Therefore, in the case of IPX and Appletalk we do not get the benefit of hierarchy. Information about destinations reachable within an area must get fed into the level 2 routers, which must in turn feed the information into all the areas. The most straightforward method of feeding information from area A into level 2, is for the level 2 routers in area A to compute reachability to all relevant destinations in A, and include Perlman (Internet-Draft expires end December 1993) [Page 7] Internet-Draft Further Integration of ISIS June 1993 those destinations as "neighbors" in their level 2 LSP. Likewise, after computing their level 2 reachability, they will add to their level 1 LSPs in area A any relevant destinations they have discovered through level 2. If we want optimal routing to protocol Y destinations, then every level 2 router would have to report an accurate cost from itself to each destination. Since we believe it is reasonable to trade off optimal routing for scaling of the routing algorithm, we propose that only a single level 2 router in each area report reachability information into or out of the area. We'll call that level 2 router the Designated Level 2 IS for area A. It is chosen based on lowest ID, of the level 2 routers in area A that support protocol Y. If none of the level 2 routers in area A support protocol Y, it is possible to leak protocol Y information into and out of A through use of a "tunnel". A tunnel in this case is manually configured between level 1 routers in two different areas. A router connected to a tunnel summarizes all the protocol Y destinations reachable within its area over the tunnel. It does not report destinations reachable from other areas that have been discovered either through tunnels or through level 2 routers. (It is possible to require a tunnel from area A even though level 2 routers in A support protocol Y, in the case where area B has no protocol-Y capable level 2 routers, in order to share information between area A and area B.) The requirement that a tunnel between area A and B only report reachability of destinations directly reachable from A and B (not learned through other tunnels or from level 2) makes things simpler, but it has the potential disadvantage that if there were n areas that needed to be connected through tunnels, there would need to be n**2 tunnels configured, and probably more to handle the case of tunnel routers being down. However, if there is a large amount of protocol Y sprinkled around the network, and therefore many areas with protocol Y information, then the cost of upgrading the level 2 routers to handle protocol Y information is relatively small. If level 2 routers can handle protocol Y information, tunnels are not necessary. We will make the restriction that Protocol Y information leaked out of area A (either through tunnels or into level 2) only include Protocol Y destination reachable within the area. The way this is enforced is to mark, in level 1 LSPs, whether Protocol Y destination D is reachable within the area or not (the "I/E" flag, see section 4.2). (Level 2 LSP does not need the flag since none of the information is intra-area.) R learns of D, and therefore reports it in its level 1 LSP in one of the following ways: Perlman (Internet-Draft expires end December 1993) [Page 8] Internet-Draft Further Integration of ISIS June 1993 1. R has been manually configured that D is reachable on one of its circuits (in which case R sets the flag, indicating D is intra-area). 2. R learned about D through a GRP neighbor (in which case R sets the flag) 3. R is a level 2 router, and has learned about D through its level 2 LSP database (in which case R clears the flag) 4. R is a tunnel endpoint, and has learned about D through the tunnel (in which case R clears the flag) 4.6. Limited Interconnectivity Over The Backbone It is possible that someone has many independently grown Protocol Y islands, and would like to interconnect some of them. The easiest way is to attach them all to the common backbone. But it may not be desired to provide full logical connectivity for various reasons: 1. Since Protocol Y (for Y=Appletalk or IPX at least) is not hierarchical, the total amount of information in IS-IS might be too great. It might be desired to limit the spread of knowledge of certain islands, since it is known that they do not need to communicate beyond a particular extent. 2. There might be security reasons why only some of the islands should be allowed to communicate with other islands. 3. There might be overlapping addresses. Proper use of CLNP and IP require acquiring guaranteed unique addresses. This is not true of IPX and Appletalk, so merging networks will not necessarily work. The method of accomplishing this is to allow configuration of when protocol Y information should be propagated. The places where such configuration is necessary are: 1. At a level 1 router -- each link should be configurable about which types of Protocol Y information should have routing information propagated across the link. For instance, in the case of IPX and Appletalk, each link would be independently configured as to which network numbers should be included in GRP information sent on that link, and as to which network numbers should be accepted from GRP for inclusion in level 1 LSPs, and propagation to other GRP neighbors on other links. So for each link, the level 1 Perlman (Internet-Draft expires end December 1993) [Page 9] Internet-Draft Further Integration of ISIS June 1993 router will be configured with a set of network numbers it should propagate to the link, and a set of network numbers to propagate from the link. Also, the level 1 router should be configured with a set of network numbers it should propagate to level 1 routing, and a set of network numbers it should propagate from level 1 routing to any link. This should be wildcardable in various ways -- either by specifying a domain (see next section), or specifying a very wide network number range. 2. At a level 2 router -- it must be configurable with network numbers it should pass from level 1 into level 2, and vice versa. 3. At a tunnel endpoint -- same configuration as for a level 2 router 4.7. Making Configuration Easier It is usually the case that for management purposes an entire island would be treated identically, in terms of where information about that island should propagate. At the expense of putting a small additional field into LSPs, it is possible to give an island a "domain" name, which could be simply a one byte field, though we may prefer a different format in order to be compatible with AURP. Then, instead of configuring a node with all the explicit network numbers to be propagated, instead the information can be summarized with a domain number. -------------+ +---------+===========+----------+ GRP | | | level | | cloud R2--+--R1 area R3 2 net R4 area R5--R6 -------------+ | A | | B | +---------+===========+-----------+ | R8--- area C For instance, R1 might be configured to declare all network numbers it hears from R2 as in "domain 7". It might further be configured that it should propagate information about everything in domain 7 into its level 1 LSP. R3 might be configured to propagate information about domain 7 into its level 2 LSP. R4, on the other hand, might be configured to ignore information about domain 7. R8 might be configured to accept information about domain 7. With very little configuration, information Perlman (Internet-Draft expires end December 1993) [Page 10] Internet-Draft Further Integration of ISIS June 1993 about all the network numbers in the GRP cloud is propagated to area C, but not to area B. So the configuration is actually two stages. First network numbers are assigned to domain numbers. In the usual case, all network numbers learned through GRP on a particular link will be assigned the domain number, so this step will be very easy. In the case of a level 2 router that is not directly connected to any Protocol Y destinations, there will be no configuration of network number/domain correspondence. This only occurs in routers directly connected to Protocol Y destinations and/or Protocol Y GRP routers. The next stage is to configure which domain numbers should be passed to and from links or from levels. For network numbers not assigned domains (and therefore, by default, being in "domain 0"), or to be able to make exceptions, it should be possible to configure network numbers in addition to domains, in the filtering information. 4.8. Accomodating Overlapping Addresses There is an additional way in which domains may be useful. They may be useful as an extension to the Protocol Y address, when encapsulation is used. At the cost of adding two extra bytes to encapsulated data packets, we can include domain information for the source and for the destination. This allows interconnection of Protocol Y islands, even if they have overlapping addresses. The way this would be accomplished is: ------------+ +-----------+ +---------------------+ A GRP | | | | B | cloud R2--+--R1 IS-IS R3---+---R4 | -------------+ | | | GRP cloud | +-----------+ +---------------------+ Suppose there are overlapping protocol Y addresses in the left and right GRP clouds. R1 could be configured to assign every network number it hears through its link to R2 as "domain 7". R3 could be configured to assign every network number it hears through its link to R4 as "domain 12". When reporting information in its LSP, R1 tags it with "domain 7". Likewise R3 tags the Protocol Y destinations it hears through R4. Now suppose A wants to send a packet to B. Let's say B is on network 3, but there's already a network 3 assigned in the left GRP cloud. R1 must be configured with mapping information. It must have an unused Protocol Y network number, say 51, and use that instead of "domain 12, network 3". A will address the Perlman (Internet-Draft expires end December 1993) [Page 11] Internet-Draft Further Integration of ISIS June 1993 packet to network 51. When it reaches R1, R1 will change the destination address inside the Protocol Y packet to "3" and include "destination domain 12" in the encapsulation header (as well as "source domain 7"). When it reaches R3, assuming that the source network number is used in the right GRP cloud, then R3 will similarly have to translate the source address in the Protocol Y header before forwarding the packet for R4. 4.9. When To Encapsulate In general we will attempt to encapsulate only if necessary. It will be necessary to encapsulate if: 1. We wish to overcome a limitation of Protocol Y, for instance the hop count limit in Appletalk 2. We wish to exploit domains for address mapping 3. Not all routers on the path support Protocol Y The LSP option announcing reachability of destination D will carry an encapsulation destination, and an indication of whether encapsulation is necessary. As an optimization, to save room in the LSP, the level 1 LSP that first announces D will not carry an encapsulation destination, since it is the source of the LSP, say R1, that is the encapsulation destination. If a level 2 router R2 then puts D in its level 2 LSP, then R2 will include R1's address as the encapsulation destination, together with a flag indicating whether encapsulation is necessary to get it from R2 to D. Destination D gets introduced into the IS-IS level 1 LSPs in area A by a router R in area A that discovers D through one of the following: 1. R has been manually configured that D is reachable on one of its ports. 2. R has a GRP (protocol Y router) neighbor that announces D in the Protocol Y specific routing protocol. 3. R is a level 2 router, and has learned about D through level 2 LSPs. 4. R is a router with a protocol Y tunnel, and has learned of D through the tunnel. Perlman (Internet-Draft expires end December 1993) [Page 12] Internet-Draft Further Integration of ISIS June 1993 In the first two cases, R will indicate that encapsulation to D is not necessary unless R has been configured to announce D as needing encapsulation. The network manager might do this for many reasons, for instance to overcome hop count limits in Appletalk data packets. R might have been explicitly configured to announce destination D as needing encapsulation, or it might be configured that a particular domain number should be announced that way, and D was configured to be in that domain number, or it might have been configured to announce all protocol Y destinations as needing encapsulation. In the third case (R is a level 2 router that has learned about D through level 2 LSPs), R will indicate that encapsulation to D is necessary if the level 2 LSP from which R hears about D indicates encapsulation is necessary. Otherwise, R will report D as not requiring encapsulation. The "don't need to encapsulate" flag is only a hint. It is possible for encapsulation to be required, even if the flag is set, because the traffic will exit the area at the nearest Protocol-Y capable level 2 router, and the path from that level 2 router to D might encounter a router that is not protocol-Y capable. In that case, the packet will get encapsulated enroute, which is not a problem. In the fourth case (R learned of D through a tunnel), R will always indicate that encapsulation is necessary. When receiving a packet for forwarding, a router R directly attached to protocol Y nodes has a mapping from protocol Y addresses to domains. If either the source or destination address is mapped to a domain other than 0 (default), then the packet is encapsulated (unless it's being forwarded directly by R to another link on which the neighbor is a protocol Y node). Otherwise, the packet is forwarded in native mode unless the neighbor to which the packet is to be forwarded is not protocol Y capable, or if the LSP that announced D indicates that encapsulation is needed (it came through a tunnel, or the level 2 router that is announcing it notices that its path to the destination requires encapsulation). 4.10. Tunnel Protocol When R1 in area A and R2 in area B have a tunnel configured, they have to exchange information. It is similar to LSP information, but actual LSPs do not flow over the tunnel. Therefore, we need to define the format of the information flowing over the tunnel. Perlman (Internet-Draft expires end December 1993) [Page 13] Internet-Draft Further Integration of ISIS June 1993 The information to be included is the Protocol Y information that would appear in a level 2 LSP. 4.11. Routing Algorithm Jeff Pickering suggested that routing to D always be toward the encapsulation destination, whether or not the packet to D needs to be encapsulated. I found this rather mind-boggling, but I finally did understand that it works just fine, and it eliminates potential suboptimality of routing, like when a packet is initially directed towards D and then, because encapsulation is required, it gets diverted towards the encapsulation destination. In most cases, the actual routes are identical whether the packet is directed towards D or towards the encapsulation destination. So the routing algorithm figures out, from possibly multiple encapsulation destinations, which is the proper encapsulation destination, and then routes to the encapsulation destination. The following rules specify how router R chooses how to route to D. 1. If there is exactly one LSP announcing D as being reachable within the area, say R1's LSP, then the packet is routed to R1 regardless of whether there might be other LSPs advertising R1. (The other LSPs will be advertising it as reachable outside the area.) 2. If two level 1 LSPs announce D, say R1's and R2's, and they both specify D as being in the area, then the packet is routed according to the least cost path to D. (The cost from R to R1 is added to R1's advertised cost to D, and the costfrom R to R2 is added to R2's advertised cost to D. If the cost through R1 is smaller, the packet is routed towards R1.) 3. Else, (all LSPs announcing D have hops (pseudohops) instead of IS-IS cost), find the LSP announcing the smallest number of hops. This applies even if some of the LSPs are level 1 LSPs and some are level 2 LSPs. The LSP advertising the smallest number of hops is chosen. If more than one LSP announces the same smallest number of hops, then a level 1 LSP is preferred over a level 2 LSP. If there is a tie among equal-level LSPs, then the LSP of the closest (in terms of IS-IS path cost) router is chosen. Once the LSP is chosen, take the encapsulation destination reported in that LSP, and the route to D is the route to Perlman (Internet-Draft expires end December 1993) [Page 14] Internet-Draft Further Integration of ISIS June 1993 that encapsulation destination. If the encapsulation destination is outside the area, then normal IS-IS routing routes to the nearest level 2 router. Note that this may not be a Protocol Y capable level 2 router. In that case, the packet to D will wind up gettingencapsulated enroute. We could change the routing decision to have routing be to the nearest Protocol Y capable level 2 router, but I don't think it's worth the complication. 5. Specific Proposal Some specifics apply to any protocol. This section contains information that is applicable to any protocol being supported by Integrated IS-IS. 5.1. Data Packet Encapsulation When Protocol Y is encapsulated in IP, IP has a one byte "protocol type" field. Assuming Protocol Y is assigned a protocol type value, an encapsulated Protocol Y packet looks like: # of octets +----------------------------------+ | IP header (with Protocol type=Y) | variable +----------------------------------+ | source domain number | 1 +----------------------------------+ | destination domain number | 1 +----------------------------------+ | original protocol Y packet | variable +----------------------------------+ When Protocol Y is encapsulated in CLNP, there must be a method of specifying the protocol type of the encapsulated packet. Either this is done by having some authority allocate the final byte of the destination address (the SEL octet) as a protocol type, or the first byte of the data becomes a protocol type, which also must be assigned by some authority. Perlman (Internet-Draft expires end December 1993) [Page 15] Internet-Draft Further Integration of ISIS June 1993 If the first byte of the data is the protocol type, the packet looks like this: # of octets +----------------------------------+ | CLNP header | variable +----------------------------------+ | protocol type | 1 +----------------------------------+ | source domain number | 1 +----------------------------------+ | destination domain number | 1 +----------------------------------+ | original Protocol Y packet | +----------------------------------+ If instead the final byte of the destination address ("the destination NSAP") is used as a protocol type, then the packet looks like this: # of octets +----------------------------------+ | CLNP header | variable +----------------------------------+ | source domain number | 1 +----------------------------------+ | destination domain number | 1 +----------------------------------+ | original Protocol Y packet | +----------------------------------+ When encapsulating the packet, the hop count (or "time to live" as it is called in many protocols) in the original Protocol Y packet should be decremented by 1. 5.2. "Protocols Supported" Field This field appears in IS-IS (10589 defined) Hellos, ES-IS (9542 defined) Hellos transmitted by ISs, and LSPs. Values must be assigned for each Protocol Y we wish to support. 5.3. Network Management Information 5.3.1. Parameters Node-wide (not Per Circuit Or Tunnel) This is for IS-IS routers that are directly attached to Protocol Y nodes. Perlman (Internet-Draft expires end December 1993) [Page 16] Internet-Draft Further Integration of ISIS June 1993 1. Protocol Y domains for which Protocol Y information should be included in level 1 IS-IS LSPs 2. Protocol Y domains for which Protocol Y information should be included in level 2 IS-IS LSPs 3. Protocol Y domains for which Protocol Y information learned from level 2 LSPs should be included in level 1 IS-IS LSPs 4. (Appletalk specific) flag for whether zone information should appear in level 1 LSP ????Perhaps a set of net number ranges for which zone information should appear in LSPs -- others would have to be gotten explicitly through ZIP. I strongly recommend we not put zone info into LSPs, and instead have that information obtained through ZIP. 5. (Appletalk specific) flag for whether zone information should appear in level 2 LSP Same comment -- I think zone information shouldn't go into LSPs 6. flag for whether encapsulation should always be flagged as necessary (for instance, to get around hop count limitations in Appletalk). Or if more granularity is wanted, a set of network numbers (which can be wildcarded, for instance by specifying a domain) for which encapsulation should be required. 5.3.2. Parameters Per Circuit 1. set of (Protocol y address, domain) pairs for that circuit. In the case of Appletalk, an "address" is a network number range) 2. set of (domain, internal protocol Y network number, external Protocol Y network number) for address remapping 3. filters for which domains information should pass into or out of this circuit 4. set of (domain, domain) pairs for which domain pairs are allowed to intercommunicate (default is "all") 5.3.3. Parameters Per Tunnel Perlman (Internet-Draft expires end December 1993) [Page 17] Internet-Draft Further Integration of ISIS June 1993 1. Same information as for a circuit, plus: 2. List of endpoint addresses, to be tried in order (or which would be acceptable if they initiate the tunnel) 3. Flag for whether this router should initiate the tunnel or not 4. Set of other routers in area that, if they are up, this tunnel should not be initiated (this is to prevent multiple tunnels between the same pair of areas from coming up) 6. Appletalk Specific Proposal In this section I'll make a specific proposal for Appletalk. A NLPID needs to be assigned for Appletalk, which will be used in data packets and in the "protocols supported" field in Hello messages and LSPs. 6.1. Appletalk Only Environments If Appletalk is the only protocol, then there are some simplifications. One can assume there is no hierarchy, so there is only level 1 LSPs, and no need for inter-area route leaking. Also, various flags become irrelevant, like the flag for requiring encapsulation, and the flag indicating whether something is reachable in the area or not. 6.2. Zone Information Appletalk requires routers to acquire a zone/LAN mapping table (where a LAN is represented by a network number range). This can be done in one of two ways: 1. With the ZIP protocol. For instance, R1 finds out about a newly reachable network number range from IS-IS router R2, either because R2 reports it in its LSP, or R2 has a tunnel to R1. In this case R1 explicitly sends an ordinary Appletalk ZIP query to R1 requesting the zones list for that network number range. The protocol message is encapsulated in a CLNP header (or whatever the backbone network layer protocol is), addressed to R2. R2 replies with the appropriate Appletalk ZIP reply, encapsulated with destination address R1. 2. By including the zones information in the LSP, or in the protocol used across the tunnel. Perlman (Internet-Draft expires end December 1993) [Page 18] Internet-Draft Further Integration of ISIS June 1993 The advantage of the first approach is that it doesn't clutter up the LSP database with potentially a large volume of information. Not only is it a large volume of information, but it doesn't change that frequently and doesn't seem like the type of thing LSP propagation was designed for. The advantages of the second approach is that the information propagates more quickly, changing the zones list for a network number range will work without ugly hackery, and it is self-stabilizing (if someone for some reason gets the zones list wrong, it will fix itself when the LSP information is periodically regenerated). We recommend the first approach, but allow configuration of routers as to which network numbers to include zone information for. A router can be configured to always include zone information, never include zone information, include or exclude it for certain domain numbers, or include or exclude it for certain network number ranges. If the information for a particular network number range is missing, routers request the missing zone information with ZIP. So the mechanisms work together. 6.3. LSPs The "protocols supported" field, which is already specified in RFC 1195, will have a value for Appletalk. Also, an option must be added for reporting reachable Appletalk destinations (network number ranges). I won't pick the option code. This option appears in level 1 as well as level 2 LSPs. The only difference is that the I/E flag is not present in level 2 LSPs. # of octets +----------------------------+ | DOMAIN | 1 +----------------------------+ | I/C | E | I/E | E.add len | IP/CLNP/Enc needed/intra-area +----------------------------+ | ENCAPSULATION DESTINATION | +----------------------------+ | # of Appletalk destinations| +----------------------------+ | H/C | COST | 1 - H/C => IS-IS cost or hops +----------------------------+ | LOW NET NUMBER IN RANGE | +----------------------------+ | HIGH NET NUMBER IN RANGE | +----------------------------+ Perlman (Internet-Draft expires end December 1993) [Page 19] Internet-Draft Further Integration of ISIS June 1993 To save room, this option allows reporting of multiple Appletalk destinations, so long as they all have the same domain number and the same encapsulation destination. The I/C flag indicates whether the encapsulation destination is IP or CLNP. The E flag indicates whether encapsulation is necessary. The I/E flag indicates whether the destination is directly reachable through the area, or whether information about it comes from a different area. The purpose of this information is so that information received from tunnels or from level 2 routers (who are relaying information from other areas) does not get re-exported through other tunnels. The rest of that octet gives the encapsulation address length, which will always be 4 for IP. In the case where the encapsulation destination is the source of the LSP, then that field is 0, indicating encapsulation address length is 0. The H/C flag indicates whether the cost given is an IS-IS cost (which is only true for the first router that introduces D into IS-IS -level 2 routers that summarize paths always revert to hops), or pseudohops. The other option is for zone information. (Note, I personally don't favor cluttering up LSPs with zone information, since zone information is rather static -- you get it once and it pretty much doesn't change. Sending it around in LSPs takes unnecessary bandwidth and memory. But some people would like to see it in LSPs. At least it is configurable, so it can be done either way.) The information in this option will be encoded as in an Appletalk ZIP reply, starting with the "ZIP function" octet. 7. Specific Proposal for IPX 7.1. Ticks Metric We will assume there is a configured scaling from IS-IS metrics to ticks. Within an area, it is therefore straightforward to find a reasonable ticks value. Assume IPX destination D is reachable in area A. Assume level 2 router R1 is exporting information about D in its level 2 LSP. R1 calculates the ticks value from itself to D and reports that in its level 2 LSP. When R2 imports information about D into area B, it calculates the ticks value from itself to R1 (based on scaling the IS-IS path cost), and adds that to the reported ticks cost in R1's LSP. Perlman (Internet-Draft expires end December 1993) [Page 20] Internet-Draft Further Integration of ISIS June 1993 7.2. LSPs The "protocols supported" field, which is already specified in RFC 1195, will have a value for IPX. Option for reporting IPX destinations: # of octets +----------------------------+ | DOMAIN | 1 +----------------------------+ | I/C | E | I/E | E.add len | IP/CLNP/Enc needed/intra-area +----------------------------+ | ENCAPSULATION DESTINATION | +----------------------------+ | # of IPX destinations | +----------------------------+ | H/C | COST | 1 - H/C => IS-IS cost or hops +----------------------------+ | ticks | +----------------------------+ | NET NUMBER | +----------------------------+ To save room, this option allows reporting of multiple IPX destinations, so long as they all have the same domain number, cost, ticks, and encapsulation destination. The I/C flag indicates whether the encapsulation destination is IP or CLNP. The E flag indicates whether encapsulation is necessary. The rest of that octet gives the encapsulation address length, which will always be 4 for IP. In the case where the encapsulation destination is the source of the LSP, then that field is 0, indicating encapsulation address length is 0. The H/C flag indicates whether the cost given is an IS-IS cost (which is only true for the first router that introduces D into IS-IS -level 2 routers that summarize paths always revert to hops), or pseudohops. I'm not sure we should bother with SAP information. I heard a rumor that SAP information will go away in IPX and be replaced by a naming service kind of thing. Perlman (Internet-Draft expires end December 1993) [Page 21] Internet-Draft Further Integration of ISIS June 1993 Option for reporting SAP information: # of octets +----------------------------+ | HOPS | 1 +----------------------------+ | SERVER NAME length | 1 +----------------------------+ | SERVER NAME | variable +----------------------------+ | SERVER ADDRESS | 12 (4=net, 6=ID, 2=socket) +----------------------------+ | .... | server info (cost, name, add) +----------------------------+ | HOPS | 1 +----------------------------+ | SERVER NAME length | 1 +----------------------------+ | SERVER NAME | variable +----------------------------+ | SERVER ADDRESS | 12 (4=net, 6=ID, 2=socket) +----------------------------+ 7.3. IPX-specific Network Management Information Same information as Appletalk. Perhaps instead of trying to calculate an inter-area ticks value by scaling IS-IS costs, we might instead configure an "area ticks increment" and a "level 2 ticks increment" and, for each tunnel, a "tunnel ticks increment". When reporting D, learned from the area, into a tunnel or into a level 2 LSP, add the area ticks increment. When reporting information learned through a tunnel, add the tunnel ticks increment configured for that tunnel. When reporting information learned through level 2 LSPs into an area, use the level 2 ticks increment. This is simpler and might be sufficiently accurate, especially since the more complex scheme of trying to figure it out isn't necessarily right (the packet won't necessarily be routed to the level 2 router that exported the route to D out of D's area, for instance). 8. Security Considerations Security issues are not discussed in this memo. 9. References Perlman (Internet-Draft expires end December 1993) [Page 22] Internet-Draft Further Integration of ISIS June 1993 [1]Callon, R.W, "Use of OSI IS-IS for Routing in TCP/IP and dual environments", RFC 1195, December 1990. [2]"Information Technology - Telecommunications and information exchange between systems - Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in Conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", International Standard 10589 (ISO submission copy), October 1991. 10. Working Group information The current co-chairs of the ISIS working group are: Ross Callon Wellfleet Communications Inc. 12 DeAngelo Drive Bedford MA 01730-2204 USA Phone: (617) 280 2436 Email: rcallon@wellfleet.com Chris Gunner Digital Equipment Corp. 550 King Street Littleton MA 01460-1289 USA Phone: (508) 486 7792 Fax: (508) 486 5279 Email: gunner@dsmail.enet.dec.com The working group mailing list is: isis@merit.edu Subscription requests should be sent to: isis-request@merit.edu Perlman (Internet-Draft expires end December 1993) [Page 23] Internet-Draft Further Integration of ISIS June 1993 11. Author's Address Radia Perlman Digital Equipment Corp. 550 King Street Littleton MA 01460-1289 USA Phone: (508) 486 7648 Fax: (508) 486 5279 Email: perlman@dsmail.enet.dec.com Chris Gunner (see chair information for address, etc.) Perlman (Internet-Draft expires end December 1993) [Page 24]